This disclosure relates to tracing interconnect circuitry, such as buses, on an integrated circuit chip.
In the past, an embedded system which had multiple core devices (processors, memories etc.) would have been incorporated onto a Printed Circuit Board (PCB) and connected on the PCB via buses. Traffic in the embedded system was conveyed over these buses. This arrangement was convenient for debugging the core devices, because debugging tools such as oscilloscopes and logic analyzers could be attached to the PCB's buses allowing direct access to the core devices.
Market demand for smaller products coupled with advances in semiconductor technology has led to the development of System-on-Chip (SoC) devices. In a SoC, the multiple core devices of an embedded system are integrated onto a single chip. In a SoC, the traffic in the embedded system is conveyed over internal buses, thus connection of debugging tools directly to the system bus is no longer possible. The resulting reduced access coupled with an increasing quantity of data being transported around the chip (due to developments of SoC technology leading to integration of multiple processing cores and higher internal clocking frequencies), has reduced the ability of external debugging tools to find and solve bugs within the system in the timescales demanded by the industry.
Thus, the development of SoC devices required associated development in debugging technology, which lead to the integration of some debug functionality onto the SoC. It is now customary for on-chip debugging circuitry to trace transactions on the internal buses of the SoC. The data rate available for transporting data to an off-chip debug controller, for example via USB, is much lower than the data rate on the internal buses. This coupled with the large quantity of transactions being transported on each bus, makes it impractical to trace every transaction on a bus and transport all of the traced transactions off-chip. Thus, it is customary to filter and/or trigger the transactions that are traced and output to the off-chip debugger.
Typically, a transaction has multiple phases spread over several bus cycles. For example, a transaction may have an address phase and a data phase. The filtering/triggering condition may be such that it is not known in the first phase of a transaction whether the transaction will match the condition. For example, if the condition is a transaction error, this may only become apparent at the end of the transaction. To deal with this, it is known to store all the information relating to each phase of a transaction as it arises, and at the end of the transaction to apply the filter/trigger condition and store the information in the trace buffer only if all the filter/trigger condition is met. This method requires all the information on each pending transaction on a bus to be stored until the transaction has completed and the filtering/triggering condition can be successfully applied. Modern bus systems may concurrently progress 16, 32 or even more transactions, each of which typically has hundreds of data bits to be traced. Thus, this approach requires extensive storage allocation to implement.